LLM Evaluation 与反馈闭环
评测要回答的是「怎么知道结果是对的」，而不是「代码能不能跑」。这一篇讲两件事：怎么把评测做可靠（裁判偏差与校准），以及怎么让线上失败反哺规则。
三种评测模式
| 模式 | 形态 | 适合 |
|---|---|---|
| 成对比较 Pairwise | judge 看两个输出，选赢家 | A/B 测试、提示迭代 |
| 带参考的单输出 | 对照已知正确答案打分 | 问答、摘要 |
| 无参考的单输出 | 按 rubric 打分，不做比较 | 生产监控 |
一条关键的选型洞察：
LLM 在「区分选项」上比「生成绝对分数」更强。成对比较比单点评分更可靠——因为 judge 只需要做判别，不需要锚定到一个它没有校准过的数值量表。
成对 + 随机顺序是比较提示变体或模型候选时的默认动作。 需要质量看板的绝对分数、或要排 N>2 个候选时，才用 Likert 式打分，而且必须先对一个人工打分的子集做校准。
Judge 的六种偏差（都有量化数据）
这块的奠基工作是 Zheng et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv:2306.05685, 2023，后续文献做了确认与扩展。
| 偏差 | 量化表现 | 缓解 |
|---|---|---|
| 位置偏差 | 倾向偏爱先出现的那个。影响通常几个百分点，但足以翻转接近的 A/B 结果 | 随机化顺序；每个配对跑两次并交换位置，只把一致的判为胜 |
| 长度 / 啰嗦偏差 | Pro / Llama / Flash 偏好更长回答（+0.24 到 +0.44）；Claude 偏好简洁（-0.12）；GPT-4o 基本中立（-0.04） | rubric 里把长度列为显式维度；事后按长度归一化；检查「最佳」输出是不是系统性地比其他更长 |
| 风格偏差（最严重） | 基线 0.40–0.76，压倒性偏好 markdown 格式。人类标注者 57% 偏好 markdown，而 4/5 的 judge 偏好 73–97%——差 17–40 个百分点 | 明确写出「格式不构成质量」 |
| 自我偏好 / 家族偏差 | 对同家族输出给更高分，自我偏好率 51.4%–86.2%。测试数据与评估者同源时，排名被系统性抬高 | 用不同家族的 judge，或集成两个并要求一致 |
| 对冲偏差 | 过度奖励适当对冲的答案、低估直接的答案，有时把自信的正确回答打得比谨慎的错误回答还低 | rubric 里加直接性与置信度的显式条目 |
| 具体性幻觉 | 奖励听起来具体的答案（数字、名字、引用），即使那些细节是编的 | 结合廉价的事实核验——引用的论文存在吗？数字对得上来源吗？ |
六种偏差都有量化数据，风格偏差最严重。
位置偏差
倾向偏爱先出现的那个。影响通常几个百分点，但足以翻转接近的 A/B 结果
└─ 缓解：随机化顺序；每个配对跑两次并交换位置，只把一致的判为胜
长度 / 啰嗦偏差
Pro / Llama / Flash 偏好更长回答（+0.24 到 +0.44）
Claude 偏好简洁（−0.12）；GPT-4o 基本中立（−0.04）
└─ 缓解：rubric 里把长度列为显式维度；事后按长度归一化；
检查「最佳」输出是不是系统性地比其他更长
风格偏差（最严重）
基线 0.40–0.76，压倒性偏好 markdown 格式
人类标注者 57% 偏好 markdown，而 4/5 的 judge 偏好 73–97%
└─ 差 17–40 个百分点
└─ 缓解：明确写出「格式不构成质量」
自我偏好 / 家族偏差
对同家族输出给更高分，自我偏好率 51.4%–86.2%
测试数据与评估者同源时，排名被系统性抬高
└─ 缓解：用不同家族的 judge，或集成两个并要求一致
对冲偏差
过度奖励适当对冲的答案、低估直接的答案
有时把自信的正确回答打得比谨慎的错误回答还低
└─ 缓解：rubric 里加直接性与置信度的显式条目
具体性幻觉
奖励听起来具体的答案（数字、名字、引用），即使那些细节是编的
└─ 缓解：结合廉价的事实核验 —— 引用的文献存在吗？数字对得上来源吗？长度偏差那条有个反直觉的补充
在被截断的配对里（长 = 确实更完整时），所有模型都正确地偏好长回答，88–100% 准确率。
这说明 judge 能区分填充与实质，但这个能力需要校准——它默认会偏向长，只有在被明确引导时才用「完整性」这把尺子。
一致性-效度悖论
高的重测信度（>0.95）可以和严重的位置偏差（>0.10）共存。
一个确定性地偏爱位置 A 的 judge，拿到完美的重测信度，同时也有最大的位置偏差。
可靠性 ≠ 效度。 「同一个 judge 每次都给一样的分」不代表那个分是对的。所以 judge 必须同时测稳定性和与人类的吻合度两件事。
去偏策略的效果排序
这是可以直接照做的部分——每种策略的增益都被量化过：
| 策略 | 效果 |
|---|---|
| 位置交换（跑两次换顺序，不一致就判平） | +4.7 pp |
| 思维链（先推理再下判断） | +7.3 pp |
| 校准过的结构化 rubric（5 准则） | 中等 |
| 组合：位置交换 + 合并 CoT 与 rubric 的提示 | +11.5 pp |
组合的效果大于单项之和，所以不要只做一样。
四个控制手段（配合上面的策略用）：
- 随机化答案顺序
- 提示里声明「长度本身不表示质量」
- 同时放入简洁版与啰嗦版但事实等价的答案（用来直接探测长度偏差）
- 低置信度或高风险案例转人工
每种去偏策略的增益都被量化过，可以直接照做。
位置交换（跑两次换顺序，不一致就判平） +4.7 pp ████
思维链（先推理再下判断） +7.3 pp ██████
校准过的结构化 rubric（5 准则） 中等
组合：位置交换 + 合并 CoT 与 rubric 的提示 +11.5 pp ██████████
└─ 组合的效果大于单项之和，所以不要只做一样
四个配套控制手段
① 随机化答案顺序
② 提示里声明「长度本身不表示质量」
③ 同时放入简洁版与啰嗦版但事实等价的答案（用来直接探测长度偏差）
④ 低置信度或高风险案例转人工
judge prompt 本身的纪律与普通提示工程同源
把 rubric 写显式、结构化：「按忠实度（0–3）、结构（0–3）、
硬错误（计数）打分」—— 含糊的 rubric 产出含糊的分数
要求先给理由再给分数 —— 就是上面的 CoT 增益
Judge 面板的陷阱
大型面板提供的多样性没有它们的规模听起来那么多：
一项研究发现 9 个 judge 只提供了约 2.0–2.5 个独立投票的信息量
└─ 应该跨 judge 的提示或模型做有针对性的多样性，
而不是加更多相似的 judgeJudge prompt 的写法
judge prompt 本身就是一次提示工程，纪律同源：
- 把 rubric 写显式、结构化——「按忠实度（0–3）、结构（0–3）、硬错误（计数）打分」；含糊的 rubric 产出含糊的分数
- 要求先给理由再给分数——就是上面的 CoT 增益
Judge 面板的陷阱
大型 judge 面板提供的多样性没有它们的规模听起来那么多。 一项研究发现 9 个 judge 只提供了约 2.0–2.5 个独立投票的信息量。
所以应该跨 judge 的提示或模型做有针对性的多样性，而不是加更多相似的 judge。
怎么把 judge 校准到能信
未经校准的 LLM judge 会批准失败轨迹——它会给你一个看起来很漂亮的数字，然后和现实脱节。步骤：
第一步：把 rubric 每个维度转成「可核验证据的是/否问题」。
不问「回答有帮助吗？」，改问：
- 是否回答了所问的问题？
- 是否给出了被要求的下一步？
- 是否用证据支撑了断言？
第二步：准备带锚点的示例——优秀、中等、差各一个，并写出各自的打分理由。
第三步：让 2–3 名领域专家独立给 100–200 个代表性输出打分，用有记录的共识流程解决分歧，然后算共识分数与 judge 分数的 Spearman 相关系数。
第四步：目标 ≥ 0.80。 judge 校准研究把 0.80 作为「非常强相关」的阈值——54 个被评估的 judge 里有 36 个达标。达不到就先修 rubric 和示例，别急着上量。
并且要主动探测：让 judge 在答案顺序、风格、长度变化时是否保持稳定。
专家之间的分歧本身也是一个上界。 在专业领域（临床、金融、安全敏感决策），人类专家自己也未必一致——那个不一致率就是任何自动 judge 的天花板。这也接上了 Reflection 里那条「用同一把尺子量同一块布」。
未经校准的 LLM judge 会批准失败轨迹 —— 校准分四步。
① 把 rubric 每个维度转成「可核验证据的是 / 否问题」
不问「回答有帮助吗？」，改问：
是否回答了所问的问题？
是否给出了被要求的下一步？
是否用证据支撑了断言？
│
▼
② 准备带锚点的示例
优秀 / 中等 / 差各一个，并写出各自的打分理由
│
▼
③ 让 2–3 名领域专家独立给 100–200 个代表性输出打分
用有记录的共识流程解决分歧
然后算共识分数与 judge 分数的 Spearman 相关系数
│
▼
④ 目标 ≥ 0.80
judge 校准研究把 0.80 作为「非常强相关」的阈值 ——
54 个被评估的 judge 里有 36 个达标
达不到就先修 rubric 和示例，别急着上量
并且要主动探测：让 judge 在答案顺序、风格、长度变化时是否保持稳定。
专家之间的分歧本身也是一个上界
在专业领域（临床、金融、安全敏感决策），人类专家自己也未必一致 ——
那个不一致率就是任何自动 judge 的天花板。和 Judge 搭配的确定性方法
不是所有评测都该用 judge。 能用确定性方法的必须用确定性方法：
| 场景 | 方法 |
|---|---|
| 工具调用正确性 | 精确匹配——工具名匹配 + 参数 schema 匹配（可选参数值匹配）。BFCL 用 AST 匹配 |
| 代码 | 执行式评测（跑测试） |
| 结构化输出 | schema 校验 |
精确匹配是最可靠的函数调用正确性方法，不需要 judge，也不受长度或位置偏差影响。
判据：开放式主观质量 → LLM judge；工具调用与代码 → 精确匹配或执行式评测。
pass@k 与 pass^k：这两个指标测的是不同的东西
| 指标 | 定义 | 测什么 |
|---|---|---|
pass@k | k 个独立样本里至少一个成功的概率 | 能力上限（常见于代码生成） |
pass^k | k 次独立同分布试炼全部成功的概率 | 可靠性与一致性（τ-bench 的主指标） |
为什么要两个：
一个 agent 通过 50% 的试炼，和另一个「一半任务总是成功、另一半总是失败」的 agent，是完全不同的两回事——但它们的 pass@k 可能一样。
pass^k能把这个方差暴露出来。
非确定性工作流必须跑重复试炼，并把 pass^k 和单次结果一起报。
两个指标测的是不同的东西。
pass@k k 个独立样本里至少一个成功的概率
└─ 测能力上限（常见于代码生成）
pass^k k 次独立同分布试炼全部成功的概率
└─ 测可靠性与一致性（τ-bench 的主指标）
为什么要两个
一个 agent 通过 50% 的试炼，
和另一个「一半任务总是成功、另一半总是失败」的 agent，
是完全不同的两回事 —— 但它们的 pass@k 可能一样。
pass^k 能把这个方差暴露出来。
推论：非确定性工作流必须跑重复试炼，
并把 pass^k 和单次结果一起报。基准：现状与污染
人类基线
| 基准 | 人类水平 |
|---|---|
| GAIA | ~92% |
| WebArena | ~78% |
| VisualWebArena | ~88.7% |
大多数公开基准还远低于这个上限——这既是空间也是提醒：模型在这些任务上还没到人类水平。
基准的更替
基准会老化，用之前要确认它还在有效期内：
| 场景 | 该用什么 | 为什么 |
|---|---|---|
| 通用 Agent | Gaia2（1,120 个人工标注场景，环境会变化） | GAIA v1 正在老化——更简单的工具调用与指令跟随任务接近解决。GPT-5 高推理模式在 Gaia2 上只拿到 42% pass@1 |
| Web 自动化 | WebArena-Verified | 原版 WebArena 任务集已被替代 |
| 双控对话 | τ²-bench 1.0.1 或更新 | 更早版本的结果不可比 |
| 编码 | SWE-bench Pro（更难的仓库任务）或 SWE-bench-Live（持续刷新） | 见下 |
基准污染
后发布的模型可能在训练时见过基准的题目。 这是现在评测最大的结构性风险。
一个标志性事件：SWE-bench Verified 在 2026 年 2 月被 OpenAI 弃用，部分原因就是污染顾虑。
对策：最终的生产评估优先用留出集或动态生成的评测集，而不是公开榜单。
还有一条反过来的警告：有审计发现至少 59.4% 的被审问题带有缺陷测试——这些测试会拒绝功能正确的提交。所以**「在公开基准上失败」也可能是基准的错**。
建议的组合
用 2–4 个基准，各覆盖一个面：
一个广域推理与工具使用
一个工作流专用
一个安全或策略套件（后果足够严重时才加）
一个从生产事故建立的自定义回归集最后那个最重要——它测的是没有任何公开基准会测的东西：你的依赖策略、输入校验、测试覆盖、允许改动的文件范围。
分层评测：聚合指标会骗人
这是这一篇里最值得记住的一条实证：
一项研究注入回归后，聚合通过率只动了 1.7–5.9 个百分点，而受影响的切片掉了 25–91 个百分点。
聚合报告会把这种损伤完全掩盖。 举个具体的形状：
「聚合通过率看着没问题，但事后复盘显示你的退款流程只在分期付款时失败。」
所以：每个指标都要按有意义的切片检查（按仓库、语言、工具、任务类型切），而且把匿名化后的案例加进永久回归套件，并按支付类型、工具路径、失败类别打标签。
聚合指标会把损伤完全掩盖。
注入回归后的实测
聚合通过率 只动了 1.7–5.9 个百分点
受影响的切片 掉了 25–91 个百分点
└─ 举个具体的形状：「聚合通过率看着没问题，
但事后复盘显示你的退款流程只在分期付款时失败。」
所以每个指标都要按有意义的切片检查（按仓库 / 语言 / 工具 / 任务类型切），
并把匿名化后的案例加进永久回归套件，按支付类型、工具路径、失败类别打标签。
分层门禁的五层，每一层都要过才发大版本
工具使用 是否调了正确的工具、参数对不对
推理质量 中间步骤是否成立
输出质量 最终结果
安全性 策略与合规
延迟与一致性 性能与稳定性
│
▼
离线门禁 ──▶ 影子流量 ──▶ 有限灰度 ──▶ 全量
└─ 每级都要在线指标健康，回滚条件在部署前定义好
三种触发时机各有分工
提交式 代码 / prompt / 工具 / 配置变更时
└─ 保持快速确定：必需的工具序列、结构化输出、
策略规则、已知回归；把贵的 LLM judge 留给发布候选
定时式 每日或每周，对稳定数据集与近期生产样本跑
└─ 抓仓库外的漂移：模型更新、API 格式变化、流量结构变化
事件驱动式 生产信号变化时，采样那个窗口，
隔离出失败的模型 / prompt / 工具 / 分群分层门禁与渐进放量
| 层 | 测什么 |
|---|---|
| 工具使用 | 是否调了正确的工具、参数对不对 |
| 推理质量 | 中间步骤是否成立 |
| 输出质量 | 最终结果 |
| 安全性 | 策略与合规 |
| 延迟与一致性 | 性能与稳定性 |
每一层都要过才发大版本。 通过离线门禁后，先影子流量，再有限灰度，只有在线指标保持健康才继续放量。回滚条件要在部署前定义好。
评测在什么时候触发
三种触发各自抓不同来源的风险：
| 触发 | 时机 | 跑什么 |
|---|---|---|
| 提交式 | 代码、prompt、工具、配置变更时 | 保持快速确定：必需的工具序列、结构化输出、策略规则、已知回归。把贵的 LLM judge 套件留给集成构建与发布候选 |
| 定时式 | 每日或每周 | 对稳定数据集与近期生产样本跑——抓仓库外的漂移：模型更新、API 格式变化、流量结构变化 |
| 事件驱动式 | 生产信号变化时 | 采样那个窗口，隔离出失败的模型 / prompt / 工具 / 分群 |
分层放量的顺序：离线门禁 → 影子流量 → 有限灰度 → 全量，每级都要在线指标健康。
一个现状数据和一个校准顺序
一项覆盖 306 名实践者、26 个领域的生产评测调查：
- 74% 主要依赖人工审查
- 约一半用 LLM judge
- 四分之三跳过了正式基准集，靠 A/B 测试和反馈填空
这说明「有一套正式评测」本身就是少数派。 也说明顺序应该是：
先有 golden set（哪怕是 20 条真实问题 + 标注答案）
↓
再接确定性检查（工具调用精确匹配、schema 校验）
↓
最后才上 LLM judge（并且先校准到 Spearman ≥ 0.80）倒过来做（先搭 judge、后补基准）会得到一个能跑、能出数、但你不知道能不能信的评测系统。
从线上 Bad Case 到规则更新
这是整条闭环的落点。Human Review 产出三元组后进入 Case Repository，定期聚类：
错误类型
├── Button Semantic Error
├── Missing Field Error
├── Page Type Error
├── Rule Conflict
└── Unknown Case再走：Failed Cases → LLM Analyze → 生成候选规则 → Regression Test → 人工 Review → Rule Update
三处设计要点：
| 要点 | 为什么 |
|---|---|
| 聚类是必须的一步 | 否则是逐个案例打补丁，规则集会越来越碎，最后变成一堆特例 |
| 候选规则必须过 Regression Test | 这是防止「修一个坏三个」的唯一机制——和上面「把案例加进永久回归套件」是同一件事 |
| 更新前仍要人工 Review | 改规则的影响范围超出单个案例，不能由模型自己决定 |
最终形态：
线上数据 → 决策系统 → 异常 Case → LLM / Human Review → Ground Truth
→ Case Repository → 规则修复 → Regression Test → 重新上线这就是 Evaluation → Feedback → Optimization Loop。 回到开头那句：「怎么知道结果是对的」比「代码能不能跑」重要一个量级——因为只有前者能形成闭环。
相关
- 置信度分层与 Human-in-the-loop —— 校准与区分度是这一层的前置条件
- Reflection —— 「同源盲区」在评测里的对应物
- Rule 与 LLM 的边界 —— 反哺的目标是规则集
- AI Coding 工作流 —— 「感觉更快 ≠ 更快」为什么必须被测量
参考
- https://blog.redlinesoft.net/posts/llm-as-a-judge
- https://changegamer.ai/resources/evaluating-ai-agents
- https://galileo.ai/blog/agent-evaluation-framework-metrics-rubrics-benchmarks
- https://thepromptbench.com/evals-and-testing/llm-as-judge-explained/
- https://llm-judge-bias.github.io/
YJ